Desde la versión 6.1 (diciembre de 2022), el kernel de Linux acepta oficialmente código en Rust. En 2023 hemos visto los primeros drivers reales en upstream y el debate dentro de la comunidad sobre cómo integrar dos lenguajes con filosofías muy distintas. Aquí cubrimos en qué punto estamos, qué módulos lo usan ya y por qué algunos veteranos del kernel lo ven con escepticismo.
El “por qué” del proyecto
El kernel de Linux acumula 30+ años de C, con todo lo bueno y lo malo: rendimiento extraordinario, control total sobre memoria y hardware, pero también una buena parte de los CVE críticos del sistema operativo causados por errores de seguridad de memoria — use-after-free, buffer overflows, data races. Microsoft estimó en 2019 que ~70% de sus vulnerabilidades anuales eran este tipo. Cifras similares en kernel.
Rust ofrece, sin GC, garantías de seguridad de memoria verificadas en compilación. La idea: si los nuevos drivers — sobre todo aquellos escritos por personas con menos años de C en el cuerpo — se escriben en Rust, una clase entera de bugs desaparece. El kernel C antiguo no se reescribe; solo se evita añadir más superficie de ataque al estilo viejo.
Estado en 2023
Lo que ya está en upstream o cerca de estarlo:
- Infraestructura: bindings de Rust a estructuras core del kernel (sk_buff, file_operations, ioctl, etc.). El “abi” de cómo Rust llama a C y viceversa.
- Driver Apple AGX (Asahi Linux): GPU de Apple Silicon, escrito en Rust por Asahi Lina. Mantiene Linux usable en Macs M1/M2.
- Driver Nvme inicial y experimentos de drivers de red en revisión.
- PHY de Ethernet (algunos).
- Filesystem PuzzleFS: experimental, pero ejemplo de subsistema completo en Rust.
Es un comienzo modesto comparado con la inmensidad del kernel, pero la dirección está marcada y la inversión de Google, Microsoft, Asahi y otros mantenedores garantiza continuidad.
Cómo funciona la convivencia C/Rust
El código Rust del kernel se compila a un blob estático que el linker integra como cualquier otro objeto. Las llamadas entre lenguajes pasan por capas de bindings generadas por bindgen, que transforman headers de C en tipos de Rust.
Restricciones importantes:
- No
std: el kernel no tiene libc ni allocator estándar. Se usa una variante mínima (alloc+ tipos kernel-específicos). unsafeabundante en bindings: la frontera entre lenguajes requiere romper algunas garantías de Rust. La idea es contenerunsafeen módulos pequeños y bien revisados.- Compilador específico: el kernel exige una versión exacta de
rustcpor release, sin tolerancia a versiones menores. Esto choca con el modelo de Rust de “siempre al día”.
El resultado es Rust, pero más restringido que en userspace. Los abstractions todavía maduran release a release.
La polémica social
Dos comunidades, dos culturas. La polémica visible más sonada del año: en 2023 algunos mantenedores de C consideran las expectativas de los desarrolladores Rust como demanda de cambio de cultura — pedir documentación más estricta de invariantes en interfaces de C que llevaban décadas funcionando “porque sí”. Eso terminó con dimisiones y discusiones agrias en la lista de correo del kernel.
Linus Torvalds ha dado apoyo público al proyecto pero también ha pedido paciencia de ambos lados. La realidad práctica: integrar dos comunidades de desarrolladores con estilos distintos en el mismo proyecto requiere más diplomacia que ingeniería.
Los argumentos en contra más razonables (no los puramente reaccionarios):
- Coste cognitivo dual. Mantenedores que revisan código en C y Rust necesitan competencia en ambos.
- Toolchain pesada. Construir el kernel ahora requiere
rustcademás degcc/clang. - Debug más complejo. Las herramientas tradicionales (kgdb, ftrace) están diseñadas para C; el soporte para Rust va detrás.
- Mantenibilidad a 20 años. El kernel debe seguir compilable décadas. Apostar por un lenguaje joven es asumir un riesgo de longevidad.
Los argumentos a favor son los obvios: clases enteras de bugs eliminados de antemano, mejor onboarding para desarrolladores nuevos, modelo de tipos más expresivo.
Qué esperar a corto plazo
Pronósticos razonables para los próximos 12-18 meses:
- Más drivers de hardware nuevo escritos directamente en Rust, especialmente donde haya grandes empresas detrás (GPU, NICs).
- Subsystems experimentales (filesystems, network stacks) con implementaciones Rust paralelas a las de C.
- Sin reescritura de partes core (scheduler, MM, VFS) — el coste y riesgo son demasiado altos.
- Continuación del debate cultural, con mejoras graduales en la documentación de interfaces.
Conclusión
Rust en el kernel de Linux es ya una realidad técnica, no un experimento académico. Los próximos años decidirán si el experimento escala — si la comunidad encuentra una forma de integrar dos culturas y dos lenguajes sin colapsar bajo el peso del cambio. La apuesta tiene sentido a largo plazo, pero el camino es más social que técnico.
Si te interesa contribuir, Rust for Linux es el punto de entrada. Síguenos en jacar.es para más sobre evolución de tecnologías base.
